Die Hermes Falle

Wie agil ist Hermes agil?

Seit Version 5.1 kann Hermes auch agil. So wird es angepriesen.

Neben 2 neuen Szenarien und einem neuen Modul, finden wir unter Hinweisen zur Anwendung denn auch ein separates Kapitel Agiles Projektmanagement mit Hermes und Scrum.

Diese Überschrift sagt klar aus, dass es sich hier um Agiles Projektmanagement handelt.

Jedoch schon die nächsten Zeilen belehren uns eines Besseren. Ab hier wird klar, lediglich die Entwicklung wird agil, nach Scrum durchgeführt. Die übrigen Phasen bestehen jedoch weiterhin und werden gemäss Hermes Definition durchlaufen. – Müssen weiterhin durchlaufen werden. Denn in Scrum sind diese Schritte und all die Kontrollmechanismen nicht definiert.

Es handelt sich also in Tat und Wahrheit nicht um agiles Projektmanagement. Sondern um klassisches Projektmanagement nach Hermes mit iterativer Entwicklung nach Scrum.

Eine iterative Entwicklung bringt enorme Vorteile! Aber wie kommt man auf die Idee dies Agiles Projektmanagement zu nennen?

Schauen wir uns an, wie Agiles Projektmanagement mit Hermes und Scrum die einzelnen Werte aus dem Agilen Manifest berücksichtigt.

Wir schätzen Individuen und Interaktion mehr als Prozesse und Werkzeuge

Tut mir leid dies so sagen zu müssen, aber Hermes ist eine einzige Vergötterung des Prozesses. Es ist vorgegeben, die Konzeption, das Testing, die Projektführung, das Risikomanagement, das Änderungsmanagement etc. zu abstrahieren und von der Entwicklung und dem Resultat separiert zu betrachten.

Die Interaktion zwischen Menschen besteht aus förmlichen Meetings und dem weiterreichen von Dokumenten.

Essenzielle Scrum Zeremonien wie Review oder Retrospektive werden schlicht ignoriert.

Agil möchte auf Änderungen und nicht Vorhersagbares reagieren können.

Dank guter Kommunikation wissen Individuen was sie weshalb tun. So können sie flexibel auf Veränderung reagieren.

Starre Prozesse können nicht auf unvorhergesehene Ereignisse reagieren. Sie verbieten dies sogar oder machen Änderungen zu einem komplizierten schleppenden Prozess.

Wir schätzen funktionierende Software mehr als umfassende Dokumentation

Schon wieder definiert hier Hermes das komplette Gegenteil. Dokumente enthalten die einzige Wahrheit, so scheint es. Denn aufgrund dieser werden Entscheidungen getroffen und der Projektverlauf bestimmt. Ich habe mir die Mühe erspart, die Worte zu zählen. Aber die Hermes Definition spricht sicherlich zu über 85% von Dokumenten und nicht von Produkten und Resultaten.

Papier ist geduldig. Wir können in den Dokumenten schreiben was wir für richtig und wichtig halten. Wir müssen sogar die reale Welt abstrahieren. Oft werden die Dokumente von Personen verfasst, die nicht direkt in die Entwicklung involviert sind. Die beschriebenen Fakten sind also schon durch unterschiedliche Filter gegangen. Oft werden gar abstrahierte Informationen weiter abstrahiert. Es gibt ja unterschiedliche Leser mit unterschiedlichen Sichten.

Auf Basis solcher Informationen will Hermes Entscheidungen fällen!

Agiles Vorgehen und Scrum tragen genau diesem Dilemma Rechnung. Kritische Entscheidungen sollen auf etwas handfestem getroffen werden – einem funktionierenden Produkt.

Mit der richtigen Priorisierung können wir so Risiken direkt konkret ausschliessen, den Wert der geleisteten Arbeit steigern, Entscheidungen aufgrund handfester Resultate treffen.

Leider ist dies jedoch im Agilen Projektmanagement mit Hermes und Scrum nicht zulässig.

Wir schätzen Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen

Hermes definiert eine sehr enge Zusammenarbeit mit dem Kunden. Der Kunde ist auf jeder Hierarchieebene vertreten. Es ist vorgesehen, dass er aktiv in das Projekt mit einbezogen wird. Hermes regelt viele Punkte der Zusammenarbeit mit dem Kunden und macht so Verhandlungen überflüssig.

Leider ist es dann im Konkreten doch wieder stark formalisiert. Dadurch ist die gute Absicht wieder zunichte gemacht.

Wir schätzen das Reagieren auf Veränderungen mehr, als das Befolgen eines Plans

Hermes investiert sehr viel Ressourcen in den vorgängig zu erstellenden Plan. Diesem Plan zu folgen ist als oberstes Ziel definiert. Abweichungen müssen durch einen Änderungsprozess laufen und abgenommen werden.

Flexibilität oder eben Agilität wird so verhindert.

Die unbürokratische, schnelle Reaktion auf Veränderungen ist einer der Hauptvorteile von agilen Vorgehensweisen. Wenn Hermes sagt uns sind Pläne und das Befolgen dieser wichtiger als Agilität. So darf es sich im Umkehrschluss auch nicht agil nennen – will sich nicht agil nennen.

Was ist hier geschehen?

Ich kann selbstverständlich nur raten. Da ich aber niemandem böse Absichten unterstellen möchte, bleibt eigentlich nur Unkenntnis als Grund übrig.

Scrum wurde durch die traditionelle Brille und mit altem Mindset als Prozess betrachtet. Zugrundeliegende Prinzipien und die Ziele der Regeln wurden ignoriert. Das macht man traditionell so.

Danach hat man Scrum durch die Hermes Schablone angeschaut und in Hermes integriert.

Die echten Vorteile des agilen Vorgehens hat man so leider verpasst.

Will man ein wahrhaft agiles Projektmanagement definieren, so muss man den traditionellen Prozess durch die agile Brille anschauen. Man muss die Schwachstellen erkennen und durch agile Praktiken verbessern. Schwachstellen an herkömmlichen Prozessen finden wir hauptsächlich überall dort, wo nicht mehr an und mit dem Produkt gearbeitet wird. Wo Risiken, Fortschritt, Qualität oder welche Grössen auch immer in Zahlen und Grafiken abstrahiert sind. Dort gibt es enormen interpretationsspiel- und -freiraum. Eine potenzielle Quelle für Missverständnisse und Fehler. Wenn kein nachweisbarer Wert generiert wird, handelt es sich um klassische Verschwendung. In der Agilität verwenden wir das konkrete Inkrement zur Standortbestimmung. An diesem gibt es nichts zu abstrahieren oder zu interpretieren, Resultate sind eindeutig. So können viele Aufgaben viel zielführender und direkter erledigt werden.

Solange wir das nicht verstanden haben und weiterhin nach Planung, Kontrolle und Nachvollziehbarkeit schreien, wird es schwierig, den Schritt in die wahre Agilität zu gehen.

Weite Verbreitung

Leider müssen wir feststellen, dass viele Unternehmen in diese Hermess Falle tappen. Nicht weil sie Hermes folgen, sondern weil sie selbst den gleichen Fehler begehen.

Ein agiles Framework wird eingeführt. Die Entwicklung geschieht nach diesem Framework iterativ. Der gesamte Plan was zu tun ist, ist aber schon erstellt. Man folgt weiter diesem Plan, anstatt aus den Inkrementen so schnell wie möglich zu lernen. So verpasst man leider den grössten Vorteil der Agilität.

Dieser Unterschied ist auch als doing agile vs. being agile bekannt. Oder das Vorgehen als Water-Scrum-Fall.

Unser Tipp

Im digitalen Zeitalter haben wir die Hilfsmittel unsere Hypothesen in kürzester Zeit live zu validieren. Profitiert davon.

Überlegt Euch, wieviel ihr unterwegs lernt und ob ihr dies nicht direkt in Eure weitere Planung einfliessen lassen wollt, anstatt an einem Plan festzuhalten, den ihr gemacht hattet, als Ihr dieses Wissen noch nicht hattet.

Macht Euch diesen Lernwillen zum Prinzip – egal nach welcher Methode ihr arbeitet.

Der Lichtblick

Das ISB (Informatiksteuerungsorgan des Bundes) hat erkannt, dass das Wort Agilität in HERMES eine Farce ist. HERMES wird aktuell überarbeitet. Es besteht die Hoffnung, dass HERMES im neuen Kleid den agilen Werten besser entspricht.

Wir sind gespannt! Erkenntnis ist ja bekanntlich der erste Schritt zur Besserung.

Wie steht es bei Euch?

Steckt ihr in der Hermes Falle und wollt es Euch nicht eingestehen?

Habt ihr es erkannt und tut etwas dagegen?

Seid ihr einen Schritt weiter und arbeitet über alle Ebenen hinweg agil?

---

---